The IBM 1130 Computing System, introduced in 1965,[1] was IBM's least-expensive computer at that time. It was aimed at price-sensitive, computing-intensive technical markets like education and engineering, succeeding the IBM 1620 in that market segment. The IBM 1800, introduced in 1966, was a process control variant of the 1130 with two extra instructions (CMP and DCM) and extra I/O capabilities. The IBM 1500 instructional system was introduced by IBM on March 31, 1966 and was based around either an IBM 1130 or an IBM 1800 computer, it supported up to 32 student work stations each with a variety of audiovisual capabilities.
Contents |
The 1130 became quite popular, perhaps 10,000 1130s were manufactured. [2] The 1130 and its non-IBM clones gave many people their first feel of "personal computing." Its price-performance ratio was good and it notably included inexpensive, removable disk storage, with a reliable, easy to use disk operating system that supported several high level languages. The low price and well balanced feature set made interactive "open shop" program development available to a large number of users for the first time. The 1130 holds a place in computing history in part because of the fondness its former users hold for it.
The IBM 1130 used System/360 electronics packaging called Solid Logic Technology (SLT) and had a 16-bit binary architecture, not very different from later minicomputers like the PDP-11 or Data General Nova.
The address space was 15-bits, limiting the 1130 to 32,768 16-bit words (65,536 bytes) of core memory. Both direct and indirect addressing capabilities were implemented.
IBM 1130s with an 'A' in their model number were delivered with 4,096 words of core memory, 'B' models with 8,092 words of core memory, 'C' models with 16,384 words, and 'D' models with the maximum supported 32,768 words of core memory.
Much programming was done in Fortran. The 1130 Fortran compiler could run on a machine with only 4,096 words of core. To maximize speed and conserve space, the operating system and compilers were written entirely in assembly language, and employed techniques seen less frequently today including tight integration of code and data as well as self-modifying code. The compiler was broken into many small "phases" that were linked to successively, each phase performing its own modifications of the representation of the source on their way towards machine code. Thus the first phase would read the source statements into memory, discarding comment lines, squeezing out all spaces (fortran syntax is unusual in that spaces are nowhere significant outside text literals) concatenating continuation lines and identifying labels, and performing no syntax checking beyond what might be discovered during this stage. It was available in a disk resident version, as well as on 8-channel punched paper tape or punched cards. In order to permit the use of programs that were too large to fit in main memory "all at one time", the implementation of the Fortran language permitted any subroutine to be designated as a "LOCAL", which stood for "Load-on-Call Subroutine". The operating system would also designate the floating-point arithmetic routines LOCAL at need. This use of disk-resident (overlay) code required the executable code for such a subroutine to be "loaded" [read] from disk in to main memory, (if it was not already present in main memory) when that subroutine was "called" (invoked). A collection of say six such routines would require only as much storage as the largest, rather than the total amount for all six.
Other programming languages available on the 1130 included: APL,[3] BASIC, COBOL, FORTH, PL/I and RPG. Even an Algol compiler, but in French, so "Debut ...Fin;" rather than "Begin ... End;" and with all messages in French, so "Bonne compilation" was the goal. Eastern Michigan University developed a Fortran IV compiler for the 1130, known as Fortran-EMU as an alternative to the Fortran II compiler provided by IBM. It added many features, including the LOGICAL data type, enhanced diagnostics, and six-letter variable names. Oklahoma State University developed an ALGOL 68 compiler [1], the compiler was written in ANSI Fortran 1966.
The basic 1130 came with an IBM 2310 voice-coil actuated disk drive, called "Ramkit", from IBM's General Products Division in San Jose.[4]:497 These read pizza-box-sized 2315 single platter cartridges that held 512 K words or 1 M byte (less than a 3.5" HD floppy). Disk memory was used to store the operating system, object code, and data, but not source code. The last was kept on punched cards. The disk operating system was called DMS or DM2 (for Disk Monitor System, Release 2).
The console typewriter used an IBM Selectric mechanism, which meant one could change the type by replacing a hollow, golf-ball sized type element. There was a special type element available for APL, a powerful array-oriented programming language using a special symbolic notation. A row of 16 toggle switches on the console typewriter could be individually tested from within programs, using the Fortran statement IF (SENSE SWITCH i), for example.
Other available peripherals included:
A standard 1130 had a 3.6 microsecond memory cycle time, with a more expensive model equipped with 2.2 µs memory cycle time. (You could use the latter with a 1403 printer connected through a 1133 multiplexer.) To further tap the low end of the market, IBM introduced the 1130 Model 4, with a 5.6 µs cycle time - at a lower price of course. The Model 4's 1132 printer was derated as well, but the slower CPU still could not keep up with it. (The 1132 used the CPU to determine when to fire the print wheels as they rotated, a very compute intensive function.) Careful readers of the 1130 hardware manual discovered that when the printer interrupt level (1) or the 1442 column interrupt (0) was on, the 1130 Model 4 ran at the faster 3.6 us cycle time. Some users of the Model 4 would write a phony printer driver that turned on level 1 and left it on for the duration of the compute-intensive part of their application. No I/O could take place during this time as even the 1442 used a level 4 interrupt to mark the end of the card. Level 0 was the highest interrupt level and level 5 was the lowest.
IBM implemented five models of the 1131 Central Processing Unit which was the primary processing component of the IBM 1130 Computing Systems.
|
Storage Speed
|
|||||
|
Storage Size
|
3.6-microsec. storage cycle |
3.6-microsec. storage cycle
plus disks |
3.6-microsec. storage cycle
(70% performance) single disk |
2.2-microsec. storage cycle plus disks |
2.2-microsec. storage cycle (no internal disk) |
| 4096 words |
Model 1A
|
Model 2A
|
Model 4A
|
---
|
---
|
| 8192 words |
Model 1B
|
Model 2B
|
Model 4B
|
Model 3B
|
Model 5B
|
| 16,384 words |
Model 1C
|
Model 2C
|
---
|
Model 3C
|
Model 5C
|
| 32,768 words |
Model 1D
|
Model 2D
|
---
|
Model 3D
|
Model 5D
|
The IBM 1800 was a variant of the IBM 1130 with additional features for process control applications. Just as the IBM 1130 was a successor to the IBM 1620, the IBM 1800 was a successor to the IBM 1710. The IBM 1500 was a multi user educational system based on the 1130 and 1800.
... I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and late-evening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.
The system was an IBM 1130 computer, a machine the size of a desk with 8KB of main memory, a 512KB disk drive, a Teletype CX paper tape reader and BRPE paper tape punch, and a Photon 713 photomechanical typesetter. The assignment was my first experience with managing a machine-readable document database: I learned to roll the punched paper tape carefully so that it could be stored neatly in cylindrical waste paper baskets.
In the meantime, though I didn't know about it, the roots of generalized markup were being planted. Historically, electronic manuscripts contained control codes or macros that caused the document to be formatted in a particular way ("specific coding"). In contrast, generic coding, which began in the late 1960s, uses descriptive tags (for example, "heading", rather than "format-17").
Main Registers:
IAR = Instruction Address Register
ACC = Accumulator
EXT = Extension Register
XRx = Index Registers x = 1,2,3
Condition indicators
+ Positive
- Negative
Z Zero
O Overflow
C Carry
E Even
1130 Instruction Set Mnemonics:
LD = Load ACC STO = Store ACC
LDD = Load Double (ACC & EXT) STD = Store Double (ACC & EXT)
LDX = Load Index STX = Store Index
LDS = Load Status STS = Store Status
A = Add ACC AD = Add Double
S = Subtract ACC SD = Subtract Double
M = Multiply D = Divide
AND = Boolean And OR = Boolean Or
XOR = Boolean Exclusive Or
SLA = Shift Left ACC SLT = Shift Left ACC & EXT
SLCA = Shift Left and Count ACC SLC = Shift Left and Count ACC & EXT
SRA = Shift Right ACC SRT = Shift Right ACC & EXT
RTE = Rotate Right ACC & EXT XCH = Exchange ACC and EXT
MDM = Modify Memory
B = Branch
BSC = Branch or Skip on Condition (Modifier dependent)
i.e. BP BNP BN BNN BZ BNZ BC BO BOD
BSI = Branch and Store IAR
MDX = Modify Index and Skip (Increment IAR one if a sign change or becomes zero)
WAIT = Halt NOP = No Operation
XIO = Execute I/O
1800 Additional Instruction Mnemonics:
CMP = Compare ACC DCM = Double Compare ACC & EXT
Short instruction format (one 16 bit word):
1
Bits 0...45678......5
OP---FTTDisp----
OP is Operation
F is format 0 = Short
TT is Tag
Disp is Displacement
Long instruction format (two 16 bit words):
1 1
Bits 0...456789.....50..............5
OP---FTTIMod----Address---------
OP is Operation
F is format 1 = Long
TT is Tag
I is Indirect bit
Mod is Modifier
Effective Address Calulation (EA):
F = 0 | F = 1, I = 0 | F = 1, I = 1
Direct Addressing| Direct Addressing| Indirect Addressing
-------------------------------------------------------------------
TT = 00 | EA = Displ + IAR | EA = Add | EA = C/Add
TT = 01 | EA = Displ + XR1 | EA = Add + XR1 | EA = C/Add + XR1
TT = 10 | EA = Displ + XR2 | EA = Add + XR2 | EA = C/Add + XR2
TT = 11 | EA = Displ + XR3 | EA = Add + XR2 | EA = C/Add + XR3
-------------------------------------------------------------------
Disp = Contents of displacement field
Add = Contents of address field of instruction
C = Contents of location specified by Add or Add + XR
The design did not employ a stack, neither in hardware nor in software. A subroutine SIMPL would be organised as follows:
SIMPL: DC *-* This is the entry point, filled with a zero initially (DC = Define Constant).
(whatever the routine does)
B I SIMPL Return by an Indirect branch, to the address found in location SIMPL.
END SIMPL Instructs the assembler that the source for routine SIMPLE is complete.
(other code)
BSI L SIMPL To invoke SIMPL. L is for Long, if the destination were more than -128 or +127 words away.
(more code)
Thus the BSI (or CALL) would store at address SIMPL the current value of IAR which would thereby be the return address. The initial value there would be zero, since "*" represents the current address during assembly so that *-* evaluates to zero but is visually distinct. Without extra arrangements to protect the return address, recursion would be impossible (if SIMPL invoked itself or a routine that invoked it, its original return address would be overwritten) and re-entrancy is precluded also for the same reason. Thus, a routine invoked during the processing of an interrupt must not invoke any routine that could have been interrupted. Additional conventions attended parameters, which might follow the BSI instruction either as values or as addresses of values, etc. Routine SIMPL might modify its return address value while accessing those parameters, and would certainly have to increment the value by the correct number of words so that the return would be to the address following the parameters.
By convention, library routines were invoked via index register three. This register would point at a series of entry point addresses, so that a particular routine would be a small offset into that table, thereby enabling the one-word instruction format to be used. Since floating-point arithmetic was performed by software, there would be many invocations of such routines. This protocol is hidden in the assembler source code example by the usage of LIBF. Fortran programs would only ever use index register one, so that register two was unused.
The convention of having a zero as the initial value at the entry point meant that if alas a return was made through the value of an entry point that had not been entered through, execution would jump to location zero of memory, which contained a jump to itself so as to entrap such mistakes.
The examples can be executed on the IBM 1130 emulator available at IBM 1130.org.
The following listing shows a card deck that compiles and runs an Assembler program that lists a deck of cards to the line printer.
The following code Copyright (c) 2006 Kym Farnik. Code published under MIT license. See: http://www.opensource.org/licenses/mit-license.php
// JOB
// ASM
*LIST
* LCARD.ASM - LIST A DECK OF CARDS TO LINE PRINTER
*
* COPYRIGHT (C) 2006 KYM FARNIK.
* CODE PUBLISHED UNDER MIT LICENSE.
*
* PROGRAM
* NEW PAGE ON PRINTER
* A READ A CARD
* CONVERT FORMAT
* PRINT A LINE ON PRINTER
* GOTO A
*
START LIBF PRNT1 GOTO NEW PAGE ON 1132
DC /3100 PRINTER CHANNEL 1-NEW PAGE
*
NEXTC LIBF CARD0 READ FROM 1442 CARD READER
DC /1000 CONTROL TO READ
DC CBUFF STORE 80 COLUMNS
CINP LIBF CARD0
DC 0
B CINP LOOP UNTIL CARD IS READ
*
LIBF ZIPCO CONVERT CARD TO PRINTER
DC /1100 UNPACKED IN, PACKED OUT
DC CBUFF+1 INPUT BUFFER
DC PBUFF+1 OUTPUT BUFFER
DC 80 CHARACTER COUNT
CALL HLEBC HOLLERITH TO EBCDIC
*
LIBF PRNT1 PRINT 80 CHARACTERS
DC /2000 CONTROL CODE TO PRINT
DC PBUFF PRINT BUFFER
DC PERR PRINT ERROR
POUT LIBF PRNT1 CHECK FOR PRINT COMPLETE
DC 0
B POUT LOOP UNTIL COMPLETE
*
B NEXTC READ NEXT CARD
*
* DATA
*
CBUFF DC 80 80 COLUMNS PER CARD
BSS 80
*
PBUFF DC 40 40 WORDS 80 CHARACTERS
BSS 40
*
PERR DC 0
B I PERR THIS RETURNS TO THE
* PRINTER ERROR HANDLER
* WHICH WILL TERMINATE THE PROGRAM
*
END START PROGRAM ENTRY POINT
// XEQ
TEST DATA 1
HELLO WORLD
TEST DATA 2
In this job, the assmbler leaves the result of its assembly in the temporary area of the system disc, and the XEQ command executes the content of the temporary area. The odd-looking "END START" has two meanings: end of assembler source, and the name of the entry point of the routine, which has the label START. Assembler source starts with column 21 of the card, not column one. In systems without a disc drive, the assembler would punch code into the start of the card just read (the card reader was actually a reader-punch, with the punch station after the read station) and then read the next card. To handle forward branches and the like, the assembler's second pass literally involved a second pass of the cards through the reader/punch. And should you need to change the source deck, you would have to duplicate the cards to obtain a deck with blanks at the start ready for the next try through the assembler.
The assembler I/O routines are typically asynchronous: the command to read a card initiates that operation and control is returned at once to the calling routine which can proceed with other activity. In this example there is no attempt at overlapping input and output with double or multi-buffering; the routine simply loops to CIMP until such time the query to CARD0 determines that the operation has been completed (which the reader had signalled via an interrupt, recognised by CARD0) and returns one word further on, thus hopping the jump back to CIMP.
The convention for buffers is that there be a word count, followed by that number of words of storage - thus the BSS 80 reserves eighty words of storage. The card buffer requires eighty words of storage, because the card reader reads the hole pattern as-is, there being twelve rows for holes or not for each of the eighty columns of the card. Thus each sixteen-bit word holds a twelve-bit sequence with ones for each hole in that column. The library routine ZIPCO packs two twelve-bit patterns into one word, but still using the card reader encodement. The console keyboard also generates twelve-bit patterns, just as if it were a card punch: this is called Hollerith code. The printer however requires EBCDIC encodements, thus the conversion from Hollerith to EBCDIC via HLEBC [except, I don't see any parameters!] after which the output area is ready for presentation to the printer, and again, the routine loops until the printer driver reports "complete" whereupon the next card is requested. This example contains no testing to determine when to stop, which would be decided by the operator instead as the card reader was being supplied with additional handfulls of cards. A more polite routine would check whether the card just read started with //, as would mark the start of the next job's deck. Such checking would have to be done at the right stage in the sequence of code conversions!
This sequential style of input and output is simple, and now usual on modern computers (certainly in DOS-derived systems), but would be unable to run the I/O devices at their best speed. The card reader in particular required close attention: only a few milliseconds after it reports "operation complete" on reading a card it will commence the card reader stop sequence, after which a new read command will have to wait to initiate another read cycle. Thus, the IBM 1402 reader could read 400 cards/minute at full speed, but, with just a little hesitancy in the read commands, its throughput dropped to 200/minute and then slower speeds still. A Fortran program could not complete even the simplest input processing in time, and so was condemned to wait for the reader's slower rate. With buffering, the card reader control could be overlapped with processing, so that the entire 150 millisecond interval between reading cards was available for processing, not just a few crucial milliseconds after each card, and the reader could be run at full speed through large data decks. But the extra complexity and buffer areas required memory, and this was often at a premium. There was a hierarchy of device drivers: those ending in Z were for Fortran, thus DISKZ, while assembler programmers might use DISK0, and DISK1 provided superior performance again when reading multiple disc sectors. But one had to attend to details: DISCZ started its sector addressing with the first available unused sector, the others started with sector zero of the disc. A "read" would obtain the bootstrap loader, and a write...
The following listing shows a card deck that compiles and runs a Fortran program and Fortran subroutine for the IBM 1130 when running DM2.
The following code Copyright (c) 2005 Kym Farnik. Code published under MIT license. See: http://www.opensource.org/licenses/mit-license.php
// JOB
// FOR
*LIST SOURCE PROGRAM
*ONE WORD INTEGERS
C-------------------------------------------------------
C COMPUTE THE CRITICAL VALUES FOR A QUADRATIC EQN
C 0=A*X**2+B*X+C
C RETURNS DISCRIMINANT, ROOTS, VERTEX, FOCAL LENGTH, FOCAL POINT
C X1 AND X2 ARE THE ROOTS
C-------------------------------------------------------
SUBROUTINE QUADR(A,B,C,DISCR,X1,X2,VX,VY,FL,FPY)
REAL A,B,C,DISCR,X1,X2,VX,VY,FL,FPY
C DISCRIMINANT, VERTEX, FOCAL LENGTH, FOCAL POINT Y
DISCR = B**2.0 - 4.0*A*C
VX = -B / (2.0*A)
VY = A*VX**2.0 + B*VX + C
FL = 1.0 / (A * 4.0)
FPY = VY + FL
FL = ABS(FL)
C COMPUTE THE ROOTS BASED ON THE DISCRIMINANT
IF(DISCR) 110,120,130
C -VE DISCRIMINANT, TWO COMPLEX ROOTS, REAL=X1, IMG=+/-X2
110 X1 = -B / (2.0*A)
X2 = SQRT(-DISCR) / (2.0*A)
RETURN
C ZERO DISCRIMINANT, ONE REAL ROOT
120 X1 = -B / (2.0*A)
X2 = X1
RETURN
C +VE DISCRIMINANT, TWO REAL ROOTS
130 X1 = (-B + SQRT(DISCR)) / (2.0*A)
X2 = (-B - SQRT(DISCR)) / (2.0*A)
RETURN
C
C NEXT STORE SUBROUTINE ON DISK USING DUP
END
// DUP
*DELETE QUADR
*STORE WS UA QUADR
// JOB
// FOR
*LIST SOURCE PROGRAM
*IOCS(CARD,1132 PRINTER)
*ONE WORD INTEGERS
C-------------------------------------------------------
C PROCESS DATA CARDS WITH A,B,C
C UNTIL A=0
C-------------------------------------------------------
DATA ICARD,IPRT /2,3/
REAL A,B,C
REAL DISCR,XR1,XR2,VX,VY,FL,FPY
WRITE(IPRT,901)
901 FORMAT(' ------------------------------------------------------')
C READ A B C, IF A=0 THEN EXIT
100 READ(ICARD,801)A,B,C
801 FORMAT(3F8.3)
C EXIT WHEN A IS ZERO
IF (A) 110,9000,110
C PRINT A B C
110 WRITE(IPRT,902)A,B,C
902 FORMAT(' QUADRATIC A=',F8.3,' B=',F8.3,' C=',F8.3)
C COMPUTE AND PRINT THE CRITICAL VALUES
CALL QUADR(A,B,C,DISCR,XR1,XR2,VX,VY,FL,FPY)
WRITE(IPRT,903) DISCR
903 FORMAT(' DISCRIMINANT=',F9.4)
WRITE(IPRT,904) VX,VY
904 FORMAT(' VERTEX X=',F9.4,' Y=',F9.4)
WRITE(IPRT,905) FL
905 FORMAT(' FOCAL LENGTH=',F9.4)
WRITE(IPRT,906) VX,FPY
906 FORMAT(' FOCAL POINT X=',F9.4,' Y='F9.4)
IF (DISCR) 120,130,140
C -VE DISCRIMINANT, TWO COMPLEX ROOTS
120 WRITE(IPRT,913) XR1, XR2
913 FORMAT(' COMPLEX ROOTS =(',F9.4,' +/-',F9.4,'I)')
GO TO 200
C ZERO DISCRIMINANT, ONE REAL ROOT
130 WRITE(IPRT,912) XR1
912 FORMAT(' ROOT X =',F9.4)
GO TO 200
C +VE DISCRIMINANT, TWO REAL ROOTS
140 WRITE(IPRT,911) XR1, XR2
911 FORMAT(' ROOTS X1=',F9.4,' X2=',F9.4)
C --- GO TO 200
C END OF QUAD
200 WRITE(IPRT,901)
GO TO 100
C END OF PROGRAM
C DATA FOLLOWS XEQ CARD
9000 CALL EXIT
END
// XEQ
+001.000+000.000+000.000
+001.000+002.000+003.000
+002.000+002.000+000.000
+002.000+000.000-004.000
+000.500+000.000-004.000
+000.250+002.000-002.000
-004.000+000.000-004.000
+002.730-007.200-003.750
+000.000+000.000+000.000
The following image shows a simple APL \ 1130 session. This session was performed via the 1130 simulator available from IBM 1130.org
The above session shows a signon, addition of the integers 1 to 100, generation of an addition table for the integers 1..5 and a sign off.